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(54) System and method for electronic transactions 

(57) A system and method for performing an elec- 
tronic transaction, including registration, audit and 
trusted recovery features. A transaction request mes- 
sage is received from a registered user that includes an 
unblinded validated certificate, and a blinded unvali- 
dated certificate. If the unblinded validated certificate is 
determined to be legitimate, then a transaction can be 
performed, and the blinded unvalidated certificate is val- 
idated to obtain a blinded, validated certificate that is 
sent to the user. An audit protocol can be used to further 
verify the legitimacy of the transaction request mes- 
sage, and a user can recover from a broken connection 
by replaying a protocol run. 
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Description 

FIELD OF THE INVENTION 

[0001] The field of this invention is electronic transac- 5 
tions, and in particular to providing electronic transac- 
tions that cannot be linked to a party to the transaction, 
even when more than one related transaction occur. 

BACKGROUND OF THE INVENTION io 

[0002] Electronic transactions should be convenient, 
reliable, accurate and resistant to fraud. Certain elec- 
tronic transactions should also protect the privacy of at 
least one party to the transaction. For example, a cus- 15 
tomer purchasing a service from a vendor over a net- 
work should be able to pay for the service in an 
electronic transaction without revealing their identity. 
[0003] The need for one party to a transaction to 
remain private (e.g., anonymous) can conflict with the 20 
interests of another party to the transaction. For exam- 
ple, a vendor needs assurance that the an electronic 
transaction is reliable, e.g., that the customer in the 
transaction will pay for the services rendered by the 
vendor. Typically, a vendor uses information about a 25 
customer to assess the vendor's risk in engaging in the 
transaction, and to track down delinquent customers 
when necessary. A good electronic transaction system 
would accommodate both the privacy needs of one 
party and the reliability needs of another party. 30 
[0004] Known electronic transaction systems gener- 
ally fail to accommodate both privacy interests and reli- 
ability interests of different parties, typically sacrificing 
one in favor of the other. One known system, an ano- 
nymizer, protects the identity of a customer from being 35 
disclosed to a vendor, but the customer identity is 
known to the anonymizer, and a customer's activity can 
be profiled across vendors. See Community Connex- 
ion, Inc. <http://www.anonymizer.com>. In a sense, the 
anonymizer is worse than a single vendor, because a 40 
single vendor can typically only profile a customer's 
behavior with respect to the vendor itself. On the other 
hand, the anonymizer can profile customer transactions 
across several vendors, not just one. The customer is 
thus forced to place considerable trust in the ano- 45 
nymizer, which if unwarranted, could lead to a substan- 
tial breach of the customer's privacy. 
[0005] Another known system uses electronic cash 
("e-cash"), wherein a customer obtains an electronic 
certificate that is redeemable at a vendor for the ven- so 
dor's product. See D. Chaum, Untraceable Electronic 
Mail. Return Addresses and Digital Pseudonyms. 
CACM 24, 2, Feb. 1981, pp. 84-88; D. Chaum, Security 
Without Identif icsflon: Tr ansaction S y s tems to Mqke Big 
Brother Obsolete. CACM (28.10). October 1985. pp. 55 
1030-1044; D. Chaum, A. Fiat and M. Naor, Untracea- 
ble Electronic Cash. CRYPTO88. pp. 319-327; E. Brick- 
ell. P. Gemmell. and D. Kravitz. Trustee-baggd Tracing 



Extensions to Anonymous Cash and the Making of 
Anonymous Change. Proceedings of the Sixth Annual 
ACM-SIAM Symposium on Discrete Algorithms, pp. 
457-466, San Francisco. California. 22-24 January 
1995; M. Franklin and M. Yung, Towards Provablv 
Secure Efficient Electronic Cash. Columbia University 
CS Technical Report. TR CUCS-018-92. 1992; and D. 
Simon, Anonymous Communication and Anonymous 
Cash. CRYPT096, pp. 61-73. One known system uses 
credit card information to carry out an electronic trans- 
action. Secure Electronic Transaction (SET) Specifica- 
tion. August 1 , 1996. As used herein, the term "product" 
includes a good and/or a service. Providing a service 
includes providing any kind of information. The elec- 
tronic certificate is meant to be spent only once, and 
can be verified by the vendor before the vendor provides 
the product. One type of fraud to which these known 
systems can be vulnerable is the multiple spending of a 
certificate. Elaborate safeguards have been designed to 
detect when a certificate submitted for a product has 
already been spent. Many of these safeguards involve 
revealing the identity of the customer, thereby violating 
the customer's privacy. 

[0006] A known technique for protecting the anonym- 
ity or a certificate owner is called blinding. See D. 

Chaum. Untraceable Electronic MaiL Return 

Addresses, an d Digital Pseudonyms. CACM 24. 2. Feb. 
1981. pp. 84-88; D. Chaum. Security Without identifica- 
tion: Transaction Systems to Make Big Brother Obso- 
lete. CACM (28,10), October 1985, pp. 1030-1044; and 
D. Chaum, A. Rat. and M. Naor, Untraceable Electronic 
Cash. CRYPTO88, pp. 319-327. A customer chooses a 
nonce and a blinding factor. A nonce is a piece of data 
that, for practical purposes, is used only once. For 
example, a random number can be a nonce. Both the 
nonce and the blinding factor are known only to the cus- 
tomer. The customer applies the blinding factor to the 
nonce (e.g., by multiplying the nonce by the blinding fac- 
tor), and submits the blinded nonce to a certification 
authority along with a payment In exchange for the pay- 
ment, the certification authority signs the blinded nonce 
to obtain a blinded certificate. The blinded certificate is 
returned to the customer. When the customer wishes to 
make a purchase, the customer unbfinds the certificate 
(e.g., by dividing the certificate by the blinding factor) to 
obtain an unblinded certificate. Because only the cus- 
tomer knows the blinding factor, no other party can cor- 
relate the unblinded certificate with the blinded 
certificate. The customer submits the unblinded certifi- 
cate along with the nonce to a vendor with a request for 
the desired product The vendor can verify the validity of 
the unblinded certificate using the nonce upon which it 
is based using techniques known in the art. Because of 
the commutativity of modular arithmetic and the mathe- 
matical nature of the signing process, the signed nonce 
corresponds to the unblinded certificate. If the 
unblinded certificate is determined to be valid, then the 
vendor makes the product available to the customer. 
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Otherwise, the product is not made available to the cus- 
tomer. 

[0007] Although the use of blinding alone protects the 
anonymity of the customer, it is not sufficient to safe- 
guard against certain types of fraud. For example, a 
customer can submit a blinded nonce to the certification 
authority along with $20, receive the blinded certificate, 
unblind it and then submit the unblinded certificate as 
being worth $100: This is possible because the certifi- 
cation authority never really sees the actual certificate it 
is signing because of the blinding factor. Thus, although 
blinding alone protects privacy, it does not by itself pro- 
vide adequate reliability. 

[0008] The problem of reliably linking a denomination 
to a certificate is addressed by the use of hash func- 
tions. A hash is a one-way function whereby it is easy to 
obtain an output from a given input, but is very difficult 
to derive an input from a given output. To obtain a certif- 
icate that only a particular customer can use, the cus- 
tomer presents a certification authority (e.g., a bank) 
with a payment and a hashed nonce. The hash function 
used by the customer is also known by the bank. The 
bank signs the hashed nonce linked to a denomination 
to obtain a certificate, which is returned to the customer. 
To use the certificate, the customer redeems the certifi- 
cate, the nonce and the denomination to a vendor, who 
in turn presents the certificate, the nonce and the 
denomination to the bank. The bank verifies the certifi- 
cate using a publicly available verification key. If the cer- 
tificate is verified as being valid, then the bank 
authorizes the vendor to provide the customer with the 
requested product, and credits the vendor's account. If 
the signature and the certificate do not correspond, then 
the bank notifies the vendor that the certificate is invalid. 
After the certificate is spent, the bank must record the 
hashed random number to prevent it from being spent 
again. The use of hash functions alone is reliable 
because in order to fraudulently spend a certificate, a 
third party would have to deduce the nonce from the 
certificate. This is made practically impossible by using 
a hash function to derive the certificate from the nonce. 
However, since the customer's certificate is known to 
the bank both during the initial certification process and 
the redemption process, the identity (and thus the pri- 
vacy) of the customer can be compromised by the bank. 
[0009] Balancing privacy and reliability interests 
across more than one transaction is challenging 
because a transaction which is reliable and private 
alone can often be correlated with other transactions 
from the same customer to compromise privacy, reliabil- 
ity, or both in known systems. Thus, a series of transac- 
tions could be unreliable and compromise privacy. As 
used herein, a series of transactions is meant to include 
both a single transaction, as well as more than one 
transaction. Privacy and reliability should be provided 
for both the case of a single transaction, and more than 
one related transaction. 

[001 0] An example of a series of transactions is a sub- 



scription service, e.g., paying a fee for a password that 
can be used to repeatedly access a service for a prede- 
termined amount of time and/or use. A subscription 
service is one in which the customer pays an initial 

5 amount to receive a product from a vendor in install- 
ments. Note that in the degenerate case, a subscription 
service includes only a single transaction. In certain 
known electronic commerce systems, the customer 
makes an initial payment to a subscription vendor, who 

10 in return gives the customer means (such as a pass- 
word) to periodically obtain the vendor's product over a 
predetermined period of time. Subscriptions are com- 
monly sold on an individual basis. Under such a policy, 
for example, two individuals seeking a subscription 

15 should pay the vendor separately; each would then 
receive her own subscription and password. If one indi- 
vidual pays for a subscription and shares her password 
with a second person, then two people are able to 
receive the subscription vendor's product while only one 

20 is paying for it This problem of sharing distinguishes an 
e-commerce system suitable for subscription services 
from known systems such as e-cash. In e-cash sys- 
tems, a certificate is meant to be fungible and readily 
transferable. In an e-commerce system capable of sup- 

25 porting subscription services, such transferability must 
be prevented or curtailed. 

[001 1 ] To counter the sharing's threat to the reliability 
of a subscription transaction, the subscription vendor 
has a strong interest in monitoring the subscribing cus- 
30 tomer's behavior to ensure that the customer is not 
sharing her subscription with others who have not paid 
the vendor. For example, unusually high activity in a sin- 
gle account could indicate fraud. e.g. ( that many differ- 
ent individuals are making use of a single subscription. 

35 On the other hand, the customer may prefer to have her 
privacy respected and not to have her activity moni- 
tored. For example, a customer subscribing to a data- 
base service may wish to keep the searches she makes 
private. Likewise, a customer ordering pay-per-use 

40 movies may wish to keep the identity of the movies he 
orders confidential. These privacy interests should be 
accommodated by a good electronic transaction system 
in a subscription-type setting. Known techniques exist 
for issuing pseudonyms, thus linking customer behavior 

45 to the pseudonym rather than to the customer. However, 
these still allow profiles (e.g.. of customer behavior) to 
be constructed if even one pseudonymous transaction 
is broken or accidentally identifies the customer. Then, 
all of the customer's past and future behavior can be 

so linked to that customer. A better system for electronic 
transactions would not suffer from this limitation. 
[0012] A good electronic transaction system would 
accommodate both the needs of the customer for pri- 
vacy and of the vendor for reliability in a single elec- 

55 tronic transaction, and in more than one related 
transaction, in part by preventing sharing. 
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SUMMARY OF THE INVENTION 

[001 3] The present invention advantageously uses the 
exchange of blinded certificates to provide a reliable, 
private system for electronic transactions that deters the 
illicit sharing of certificates for such transactions. Rather 
than operating like e-cash, in which a payment vehicle is 
redeemed for a product (as used herein, the term "prod- 
uct" means goods and/or services) in a way that 
changes the funds available to the customer, the 
present invention acts more like a membership pass. 
That is, the customer starts with a certificate, gains 
access to a product in exchange for the certificate, and 
ends with both the product and a certificate. Unlike e- 
cash, the value of the customer's use of certificates in 
accordance with the present invention is related to the 
amount of time (or number of certificates) remaining in 
the customer's contract (e.g., membership or subscrip- 
tion term). Theoretically, this could allow the customer 
to be profiled by tracking the number of certificates used 
(or available for use) by the customer. However, this 
would not be a practical problem for applications where, 
for example, thousands of people subscrfoe to some- 
thing that can only be used 5 times. Indeed, knowing 
that a customer has. say, three certificate redemptions 
left cannot reveal very much to a vendor. Audit and 
trusted recovery methods are provided to enhance the 
security and robustness of the present invention. 
[0014] The present invention is private and reliable 
both for a single electronic transaction, and a series of 
related transactions. In accordance with an embodi- 
ment of the present invention, a first party (e.g., a cus- 
tomer) registers with a registrar to obtain an initial 
validated certificate. In one embodiment, the registrar is 
a second party. In subsequent transactions, a first party 
(e.g., a customer) submits a validated certificate along 
with an unvalidated certificate to a third party (e.g., a 
vendor) for each transaction. The third party tests the 
validity of the certificate purported by the first party to be 
validated. If it proves to be valid, the third party performs 
a response action (e.g.. provides a service) and ordinar- 
ily validates the unvalidated certificate and returns it to 
the first party to be used as the validated certificate for 
the next transaction. Alternatively, the registrar (H differ- 
ent from the third party, then in cooperation with the 
third party) can declare an audit, and determine if the 
first party has presented its certificate fraudulently. 
These exchanges are atomic in nature, meaning that 
they can be reliably correlated with each other (e.g., a 
practically unforgeable secret session key is sent along 
with each related message in the exchange, guarantee- 
ing that the messages are part of the same transaction). 
[001 5] In an alternative embodiment, the registrar is a 
vendor. 

[0016] Hashing of random numbers Q.e. t nonces) and 
the technique of blinding are used in the present inven- 
tion to provide unlinkable certificates. As known in the 
art the technique of blinding is used differently, e.g.. to 



provide pseudonyms in an alternative to a universal 
identification system. See D. Chaum, Security Without 
Identification: Tran saction Syste ms to Make Bio Brother 
Obsolete. CACM (28.10), October 1985. pp. 1030- 

5 1044. Each such pseudonym is supposed to identify its 
owner to some institution and not be linkable across dif- 
ferent institutions. The present invention is designed to 
provide certificates that are designed to be unlinkable 
both across institutions and across transactions within a 

10 single institution. In particular, the present invention pre- 
vents a vendor from linking transactions to a single cus- 
tomer, even if that customer had to identify itself initially 
(e.g. f during the registration process). At the same time, 
the present invention advantageously allows the vendor 

75 to protect itself against customers that abuse the ven- 
dor's service. 

[001 7] Another difference between the present inven- 
tion and the prior art is the manner in which blinding is 
performed. In known systems, some mechanism is typ- 

20 ically needed to assure either the issuing bank or 
receiving vendor that the certificate blindly signed by the 
issuer has the right form, i.e., that the customer has not 
tricked the signer into signing something inappropriate. 
The present invention advantageously eliminates this 

25 requirement by providing assurances in other parts of 
the system, simplifying the blinding scheme. 

BRIEF DESCRIPTION OF THE DRAWINGS 

30 [0018] 

FIG 1 shows a flow chart illustrating an embodiment 
of the initialization method of the present invention. 
FIG 2 shows a flow chart illustrating an embodiment 
35 of the electronic transaction method of the present 
invention. 

FIG 3 shows a flow chart illustrating an embodiment 
of the audit method in accordance with the present 
invention. 

40 FIG 4 shows a flow chart illustrating an embodiment 
of the method for recovering from a broken connec- 
tion in accordance with the present invention. 
FIG 5 shows an embodiment of the apparatus in 
accordance with the present invention. 

45 

DETAILED DESCRIPTION 

[0019] An embodiment of the registration method in 
accordance with the present invention is shown in FIG 

so 1 . A registrar receives an initialization request message 
that atomically binds authorization data with a blinded 
unvalidated certificate to be validated, step 101. In one 
embodiment of the present invention, the registrar is a 
vendor. In another embocfiment. the registrar is a third 

55 party. 

[0020] An example of authorization data is a payment. 
Another example of authorization data is access per- 
mission (e.g. f an access code, one-time password, etc.) 
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An example of a blinded unvalidated certificate is a 
hashed nonce combined with a blinding factor. 
[0021] The registrar determines if the authorization 
data is valid, step 102. If it is determined to be valid, 
thai the blinded unvalidated certificate is validated to 5 
obtain a blinded validated certificate, step 103. For 
example, the registrar signs the blinded unvalidated cer- 
tificate to validate it The registrar party then sends an 
initialization response message that includes the 
blinded validated certif icate atomically bound to the ini- w 
tialization request message, step 104. The initialization 
request message can be atomically bound to the initial- 
ization response message by including in both a secret 
encrypted session key that reliably identifies both mes- 
sages as being bound to each other. is 
[0022] An embodiment of the registration protocol is 
shown in the following exchange of messages: 

Message 1: C->V: {Payment. 

KcvJ.fRequest for certificate of type S, C, h(N1)1Kcv so 
Message 2: V->C: [hjCNIJjs 

The first message is from a customer with customer 
identifier C to a registrar, which in this embodiment is 
vendor V. The portion of the message in the brackets 0 25 
is confidential. For example, in one embodiment, the 
portion of the message in the brackets is encrypted. In 
another embodiment, the confidentiality of this portion 
of the message is protected by sending it over a secure 
path between C and V. The confidential portion of the 30 
message in this embodiment is a Payment and a "ses- 
sion key,* Kcv. The Payment in one embodiment is elec- 
tronic cash. In another embodiment it is a credit card 
number. Session key Kcv is used throughout a single 
protocol run (e.g., of registration, redemption, etc.), 35 
although it should be changing in a way that depends on 
the previous messages of that run. However, a session 
key from one transaction shotdd be unrelated to the ses- 
sion key of any other transaction in order to prevent a 
set of transactions from being linked. It should be noted 40 
that a "run" or single transaction refer to an embodiment 
of a single instance of a method in accordance with the 
present invention. For example, a single run of an 
embodiment of a redemption transaction would involve: 
receiving a transaction request message that atomically 45 
binds an unblinded certificate and a blinded unvalidated 
certificate to be validated; determining if the unblinded 
certificate is valid; and if the unblinded certificate is 
valid, then performing a transaction response that 
includes validating the blinded unvalidated certificate to so 
obtain a validated blinded certificate; and sending the 
validated blinded certificate atomically bound to the 
transaction request message to a transaction response 
recipient in a transaction response message. 
[0023] The portions of the Messages in the braces 0 ss 
is authenticated. That is, the recipient is provided with 
the means to ensure that the purported sender is the 
true sender. As shown above, the portion of the mes- 



sage in the braces is authenticated by signing it with the 
cryptographic key secretly sent in the confidential por- 
tion of the message. The authenticated portion includes 
a request for a certificate for a particular type of service, 
S, the customer identifier, C, and a blinded hashed 
nonce H(N1> . The nonce N1 is hashed so that, given the 
hashed nonce h(N1), it is difficult to obtain the corre- 
sponding nonce. Nl, but given the nonce, N1. it is rela- 
tively straightforward to obtain the hashed nonce, h(N1). 
This is an advantageous property during the redemp- 
tion process. In one embodiment, the registration proc- 
ess further includes an authenticated acknowledgment 
message: 

Message 3: C->V: [Ack]Kcv 

[0024] An embodiment of the redemption process in 
accordance with the present invention is shown in FIG 
2. A first party (e.g., a customer) unblinds a validated 
Winded certificate, step 201. The blinded validated cer- 
tificate was validated either by a registrar as the result of 
a successful registration (see FIG 1 , step 103), or by a 
second party (e.g., a vendor) as the result of a success- 
ful earlier redemption. A transaction request message is 
received at the second party from a registered first party 
(e.g.. a registered customer), step 202. The transaction 
request message atomically binds an unblinded certifi- 
cate with a blinded unvalidated certificate to be vali- 
dated. In one embodiment of the present invention, the 
blinded unvalidated certificate is a blinded hashed 
nonce. The second party determines if the unblinded 
certificate is valid, step 203 If the unblinded certificate is 
valid, then a transaction response is performed, step 
204. 

[0025] An embodiment of the redemption process is 
shown in the following exchange of messages: 

Message 1: C->V: {[h(N(i))]s. Ni, 

Kcv}[Request for transaction of type S. 
h(N(it1))]Kcv 

Message 2: V->C: [Approved]Kcv OR 
[Not Approved] Kcv 

Message 3: C<->V: [Transaction]Kcv 

Message 4: V->C: fhfNfl+IMs 

In Message 1, a validated unblinded hashed nonce 
h(Ni) is sent with the nonce, Ni and key Kcv are sent 
confidentially from the customer C to the vendor V. Also 
sent is an authenticated request for a transaction of type 
S and an unvalidated blinded hashed (new) nonce. 
h(N(i+1)). The vendor performs the one-way hash func- 
tion on nonce Ni and compares the result to the vali- 
dated unblinded hashed nonce h(Ni). If the two 
correspond, then the vendor determines that the vali- 
dated unblinded hashed nonce is a valid certificate, 
sends an approval message in Message 2, and 
engages in the transaction in Message 3. Finally, the 
vendor validates the blinded hashed nonce of Message 
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1 and sends it to the customer. In one embodiment, the 
customer then sends an authenticated acknowledg- 
ment message upon receiving the validated blinded 
hashed nonce from the vendor: 

5 

Message 5: C->V: [AckJKcv 

[0026] In one embodiment of the present invention, a 
transaction response includes validating the blinded 
unvalidated certificate to obtain a validated blinded cer- 10 
tificate. and sending the validated blinded certificate 
atomically bound to the transaction request message to 
a transaction response recipient A transaction 
response recipient can be the first party (e.g.. customer) 
or another party. For example, in one embodiment, a 15 
transaction response is a gift sent to a third party. In 
another embodiment a transaction response message 
is a control signal sent to a piece of factory equipment. 
In one embodiment, the present invention provides a 
way for anonymous monitoring of a piece of equipment 20 
When the status of the equipment is desired by an 
authorized (i.e., registered) entity, the entity sends an 
unblinded validated certificate and blinded unvalidated 
certificate to the equipment, which sends back status 
data along with a validated blinded certificate in accord- 25 
ance with the present invention. 
[0027] In a subscription service, the certificate 
exchange may be repeated each time the subscriber 
(the first party) purchases an installment of the sub- 
scription from the vendor (the second party). An install- 30 
merit of the subscription can include the transmission of 
information that is sent each time a validated blinded 
certificate is sent to the subscriber. For example, the 
results of a database search can be sent each time a 
validated blinded certificate is sent to the subscriber. 35 
[0028] In one embodiment of the present invention, 
audit data is included to help protect against fraud. The 
transaction request message atomically binds an 
unblinded certificate, a blinded unvalidated certificate to 
be validated, and blinded audit data. Not every mes- 40 
sage is audited, so the blinding of the audit data pro- 
tects the privacy of the first party when no audit is 
performed. 

[0029] Aucfits are typically performed randomly in 
accordance with the present invention. However, audits 45 
can also be triggered, for example, by unusual service 
activity that may indicate that a subscriber is sharing its 
certificates with other, non-paying parties. For example, 
an exceptionally high volume of traffic accessing a data- 
base or telephone service may indicate a heightened so 
necessity for audits of transaction requests accessing 
the database or service. 

[0030] An embodiment of the audit method in accord- 
ance with the present invention is shown in FIG 3. Dur- 
ing registration, the customer provides an audit secret ss 
to the registrar, step 301. In this embodiment, the regis- 
trar is also the vendor. In another embodiment the reg- 
istrar is a third party. During the redemption process, 



every transaction request message from the customer 
includes a blinded version of the audit secret Thus, the 
vendor receives a transaction request message with a 
blinded audit secret, step 302. Rather than sending an 
audit response message to the customer, the vendor 
sends an audit request message atomically bound to 
the transaction request message, step 303. The vendor 
receives an audit response message from the customer 
that includes audit response data, step 304. In one 
embodiment, the audit response data includes an audit 
secret and the audit blinding factor. As with the blinded 
certificate, the audit blinding factor is combined with the 
audit secret in transaction requests to hide the audit 
secret from the vendor until an audit is initiated by the 
vendor. The vendor determines if the transaction 
request message of step 302 is legitimate using the 
audit response data, step 305. In one embodiment the 
transaction request message is legitimate if the audit 
secret combined with the blinding factor provided in the 
audit response message corresponds to the blinded 
audit secret received in the transaction request mes- 
sage of step 302. If the transaction message of step 302 
is determined to be legitimate, step 306, then the ven- 
dor validates the blinded unvalidated certificate 
received from the customer in the transaction request 
message of step 302, step 307. The vendor then sends 
the validated blinded certificate to the customer, step 
308. ff the transaction request message of step 302 is 
determined not to be legitimate, step 306, then in one 
embodiment, the customer's transaction is terminated, 
step 309. That is. no certificate is validated and returned 
to the customer. 

[0031 ] An embodiment of the redemption process with 
audit features included in accordance with the present 
invention is shown in the following exchange of mes- 
sages: 

Message 1: C->V: {[h(N(i))]s. Ni. 

Kcv}[Request for transaction of type S. h(N(M-D) . 

h(Ni, Audit_Secret, Salt)]Kcv 

Message 2: V->C: [Approved] Kcv OR 

[Not Approved] Kcv OR [AuditJKcv 

Message 3: C<->V: [Transaction] Kcv 

Message 4: V->C: [h(Nfl+1»1 s 

The messages are the same as for the redemption pro- 
tocol except for the following: First, a hashed combina- 
tion of the nonce Ni, audit secret Audrt_Secret and Salt 
is included in Message 1 . Salt is a random number that 
is a nonce. The purpose of Salt is explained below. Sec- 
ond, a response option has been added to Message 2, 
i.e., initiating an audit with an authenticated audit initia- 
tion message [Audit]Kcv. 

[0032] An embodiment of the audit process in accord- 
ance with the present invention is shown as follows: 

Message 1: C->V: tfh(N(i))]s, Ni. 
Kcv}[Request for transaction of type S, h(N(i+1)), 



6 



awonorirv <-cp 



11 



EP 0 938 068 A2 



12 



h(Ni, Audit_Secret. Salt)]Kcv 

Message 2: V->C: [Audit]Kcv 

Message 3: C-> V: {C, Ni, 
AucRt_Secret, SaltJKcv 

Messaged V->C: [H(N(i±l)]s OR [Not s 
Approved] Kcv 

[0033] Message 1 is a transaction request with audit 
features. In message 2, the vendor V initiates an audit 
by sending an authenticated audit initiation message. 10 
The customer sends an audit response message to the 
vendor. The audit response message in this embodi- 
ment includes audit data comprising the customer iden- 
tifier, C. the nonce Ni, an audit secret Audit_Secret, and 
Salt. The vendor in this embodiment is also the regis- is 
trar, and so has the Audit_Secret received from cus- 
tomer C during the registration process. First, the 
vendor compares the audit secret received in Message 
3 with the audit secret received from the customer in the 
customer's registration message. These must corre- so 
spond in order for the vendor to determine that Mes- 
sage 1 is legitimate. The vendor also hashes the audit 
secret nonce and salt received in Message 3 and com- 
pares it to the hashed combination of the audit secret, 
nonce and Salt received in Message 1 . These must also 25 
correspond so that the vendor knows that the audit 
secret provided by the customer in Message 3 is the 
same as the audit secret embedded in Message 1 . If 
both of these correspondences are established, then 
the transaction response message (Message 1) is 30 
determined to be legitimate, and a validated blinded 
hash is sent to the customer in Message 4. In one 
embodiment of the present invention, an authenticated 
acknowledgment message is sent from the customer to 
the vendor when the customer receives Message 4: 35 

Message 5: C->V: [Ack]Kcv 

The purpose of the Salt in the above messages is to 
protect the anonymity of the customer and the unlinka- 40 
bility of the customer's transactions based upon audit 
information. Without Salt, a vendor could associate a 
transaction request message with a customers identity 
using h(Ni,Audit_Secret) received in the transaction 
request message. Recall that when the vendor is the 45 
registrar, the vendor has a record of audit secrets 
received during the registration process from customer, 
with each audit secret associated with a customer iden- 
tifier. A vendor could hash the nonce Ni received in a 
transaction request message with the audit secrets it so 
knows from registration until a match is found with the 
audit data received in the transaction request message. 
In order to prevent such an exhaustive search from 
revealing a customer identity, nonce Salt is hashed with 
the audit secret and nonce Ni in each transaction ss 
response message. Because Salt is a nonce, it changes 
from message to message, rendering the audit data in a 
transaction request message untraceable by the ven- 



dor. 

[0034] The audit features of the present invention 
advantageously deter the illicit sharing of certificates. A 
non-paying party is not likely to have the audit secret, 
which in one embodiment is a credit card number, or 
other valuable data for which the registered customer 
has a strong incentive to keep confidential. This pro- 
vides a disincentive for sharing the data that is needed 
to pass an audit. Illicitly sharing a subscription also 
incurs a risk of subscription termination, and is thereby 
further deterred by the present invention. 
[0035] The present invention terminates a series of 
transactions simply by not validating and returning an 
unvalidated blinded certificate as part of the last trans- 
action. 

[0036] The present invention further provides for 
trusted recovery from a broken connection, or from 
some other interruption in the methods of the present 
invention. In one embodiment of the present invention, 
an interrupted protocol is replayed in its entirety (except 
for the actual transaction, which is always skipped) with 
the same session key, nonce and blinding factor. The 
present invention advantageously does not release any 
new information when a protocol is replayed. 
[0037] In one embodiment, broken protocols are con- 
sidered to be automatically acknowledged after some 
predetermined period of time, after which the customer 
cannot recover from the break, and replay is not 
allowed. If a connection breaks after the receipt of a 
new validated blinded certificate has been acknowl- 
edged by the customer in the redemption protocol, then 
the customer can simply use the new certificate in the 
next transaction request. 

[0038] If the connection breaks before the customer 
has received the new validated blinded certificate in the 
redemption protocol, then the protocol is replayed. An 
embodiment of the trusted recovery protocol is shown in 
FIG 4. The vendor stores the messages of each proto- 
col run (one instance of Messages 1 through 4 of the 
redemption protocol above), step 401 until the vendor 
receives an acknowledgment message from the cus- 
tomer indicating that the customer has received the new 
certificate (Message 5 in the redemption protocol), or 
until the predetermined automatic acknowledgment 
time has elapsed, step 402. When the customer real- 
izes the connection has been broken, step 403, the cus- 
tomer replays the protocol run starting from the 
transaction request message (Message 1 of the 
redemption protocol), step 404. The vendor identifies 
the presented certificate as already spent, and consults 
its recovery database (in which the protocol runs are 
stored), step 405. If the recovery database indicates 
that no acknowledgment from the customer has been 
received, step 406. then the vendor returns the stored 
response, step 407. As mentioned above, the transac- 
tion is skipped, but the customer receives a new vali- 
dated blinded certificate to use in the next protocol run 
to engage in the transaction. Note that the customer 



7 



BNSDOCID: <EP 093806SA2 L> 



13 



EP 0 938 068 A2 



14 



does not identify itself during recovery in accordance 
with the present invention, advantageously protecting 
the customer's anonymity. 

[0039] One embodiment of the present invention pro- 
vides a membership that charges a fee for some or all of s 
the transactions with a customer. For example, in one 
embodiment, the vendor becomes a mint for simple, sin- 
gle denomination digital tokens. The digital tokens cor- 
respond to digital cash roughly as tokens in a game 
arcade correspond to cons. The vendor can bill for io 
these tokens by credit card, or some other suitable 
mechanism. 

[0040] The customer spends previously purchased 
tokens during an electronic transaction in accordance 
with the present invention. In one embodiment, the is 
tokens are spent in a transaction request message, and 
the vendor does not send a validated, blinded certif icate 
to the customer unless the payment in tokens is valid 
and sufficient. In another embodiment, a transaction 
request message includes a credit balance, which must 20 
be paid periocfically. Using a credit balance may, how- 
ever, allow a vendor to link transactions and even tie 
them to customers, since the credit balance increases 
monotonicaliy. 

[0041] In accordance with an embodiment of the 25 
present invention, a certificate presented by the cus- 
tomer operates as a bearer authentication note that 
serves to reliably identify a member of a particular 
group (e.g.; customers that have subscribed to a partic- 
ular service) without compromising the group members' 30 
privacy. No certificate (bearer authentication note) can 
generally be linked by the vendor to any other, and so 
the transactions are anonymous. 
[0042] Another embodiment of the present invention 
is used for voting. In this embodiment, a voter registers 35 
and receives a validated, blinded certificate to cast in a 
vote. The registration process ensures, for example, 
that each voter is entitled to cast only one vote. In one 
embodiment, a different electronic destination is pro- 
vided for each option for which the vote may be cast 40 
The voter unwinds the validated, blinded voting certifi- 
cate and sends it to the destination corresponding to the 
option for which the voter chooses to vote. In another 
embodiment, the voter indicates its choice in a certifi- 
cate, blinds "rt. sends it to be certified, receives it back, 45 
unblinds rt, and sends it to an electronic destination. For 
example, in an election with two choices, an even ran- 
dom number (nonce) corresponds to the first choice, 
and an odd random number (nonce) corresponds to the 
second choice. The voter picks an odd or even nonce in so 
accordance with the voter's choice, and votes in 
accordance with the present invention. This advanta- 
geously avoids having to designate different destina- 
tions for different votes. 

[0043] An embodiment of an apparatus in accordance 55 
with the present invention is shown in FIG 5. A server 
501 includes a processor 502 coupled to a memory 503 
that stores transaction instructions 504 that are adapted 



to be executed on processor 502. Server 501 further 
comprises a port 505 that is adapted to be coupled to a 
network 506. Port 505 is coupled to processor 502 and 
memory 503. A client (e.g., a customer) 507 is also cou- 
pled to the network 506. 

[0044] Examples of memory 503 include a hard disk, 
Read Only Memory (ROM), Random Access Memory 
(RAM), a floppy disk, and any other medium capable of 
storing digital information. 

[0045] Transaction instructions 504 can be distributed 
in accordance with the present invention stored on a 
medium. Examples of a medium that store the transac- 
tion instructions adapted to be executed by processor 
502 include a hard disk, a floppy disk, a Compact Disk 
Read Only Memory (CD-ROM), flash memory, and any 
other device that can store digital information. In one 
embodiment, the instructions are stored on the medium 
in a compressed and/or encrypted format. As used 
herein, the phrase "adapted to be executed by a proces- 
sor" is meant to encompass instructions stored in a 
compressed and/or encrypted format, as well as 
instructions that have to be compiled or installed by an 
installer before being executed by the processor. 
[0046] In one embodiment of the present invention, 
transaction instructions 504 are adapted to be executed 
by processor 502 to perform the steps of initializing a 
series of electronic transactions. For example, the 
instructions are adapted to be executed by processor 
502 to receive an initialization request message that 
atomically binds authorization data and a Winded unval- 
idated certificate to be validated; determine if the 
authorization data is valid; if the authorization data is 
valid, then to validate the Winded unvalidated certificate 
to obtain a Winded validated certificate; and to send an 
initialization response message to a registrant that 
includes the Winded validated certificate atomically 
bound to the initialization request message. 
[0047] In another embodiment of the present inven- 
tion, transaction instructions 504 are adapted to be exe- 
cuted by processor 502 to perform an electronic 
transaction, e.g., to receive a transaction request mes- 
sage that atomically Wnds an unWinded certificate and 
a Winded unvalidated certificate to be validated; deter- 
mine if the unWinded certificate is valid; and if the 
unblinded certificate is valid, then to perform a transac- 
tion response that validates the Winded unvalidated cer- 
tificate to obtain a validated Winded certificate, and 
sends the validated blinded certificate atomically bound 
to the transaction request message to a transaction 
response recipient in a transaction response message. 
[0048] In yet another embodiment, transaction instruc- 
tions 504 are adapted to be executed by processor 502 
to audit an electronic transaction, e.g.. to receive a 
transaction request message that atomically binds an 
unblinded certificate and a Winded unvalidated certifi- 
cate to be validated and Winded audit data; to send an 
audit request message atomically bound to the transac- 
tion request message to an audit recipient; to receive an 
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audit response message atomically bound to the audit 
transaction message, where the audit response mes- 
sage includes audit response data; and to determine if 
the blinded audit data is valid using the audit response 
data. 5 
[0049] Yet another embodiment of the present inven- 
tion includes transaction instructions 504 that are 
adapted to be executed by processor 502 to recover 
from an interruption in an electronic transaction in 
accordance with the method of the present invention. 10 
[0050] The present invention advantageously pro- 
vides for anonymous, unlinkable electronic transactions 
that assure the vendor of payment while protecting the 
privacy of the customer. 

[0051] Where technical features mentioned in any is 
claim are followed by reference signs, those reference 
signs have been included for the sole purpose of 
increasing the intelligibility of the claims and accord- 
ingly, such reference signs do not have any limiting 
effect on the scope of each element identified by way of 20 
example by such reference signs. 

Claims 

1 . A method for initializing a series of electronic trans- 25 
actions, comprising the steps of: 



2. 



3. 



4. A method for recovering from an interruption in ini- 
tializing an electronic transaction, comprising the 



steps of: 

a. receiving a first initialization request mes- 
sage from a registrant that includes a nonce, a 
session key. and a blinding factor applied to the 
nonce, and that atomically binds 

i. authorization data, and 

ii. a blinded unvalidated certificate to be 
validated; 

b. storing the initialization request message in 
a recovery database; 

c. determining if the authorization data is valid; 

d. if the authorization data is valid, then validat- 
ing the blinded unvalidated certificate to obtain 
a blinded validated certificate; 

e. sending a first initialization response mes- 
sage to a registrant that includes the blinded 
validated certificate atomically bound to the ini- 
tialization request message received in step a; 

f. storing the first initialization response mes- 
sage in a recovery database; 

g. receiving a second initialization request 
message; 

h. determining if the second initialization 
request message has the same nonce, session 
key, and blinding factor applied to the nonce as 
the first initialization request message stored in 
the recovery database; and 

i. if the second initialization request message 
has the same nonce, session key, and blinding 
factor applied to the nonce as the first initializa- 
tion request message, then 

1. retrieving the first initialization response 
message from the recovery database; and 

2. sending the first initialization response 
message to the registrant 

5. A method for performing an electronic transaction, 
comprising the steps of: 

a. receiving a transaction request message 
that atomically binds 

i. an unblinded certificate, and 

ii. a blinded unvalidated certificate to be 
validated; 

b. determining if the unblinded certificate is 
valid; and 

c. if the unblinded certificate is valid, then per- 
forming a transaction response that includes: 

i. validating the blinded unvalidated certifi- 
cate to obtain a validated blinded certifi- 
cate, and 



a. receiving an initialization request message 
that atomically binds 

30 

i. authorization data, and 

ii. a blinded unvalidated certificate to be 
validated; 

b. determining if the authorization data is valid; 35 

c. if the authorization data is valid, then validat- 
ing the blinded unvalidated certificate to obtain 
a blinded validated certificate; and 

d. sending an initialization response message 

to a registrant that includes the blinded vali- 40 
dated certificate atomically bound to the initial- 
ization request message received in step a. 

The method of claim 1, further comprising the step 
of receiving a registration acknowledgment mes- 45 
sage from a registrant acknowledging that the reg- 
istrant has received the initialization response 
message. 

The method of claim 1, wherein the initialization so 
request message includes a nonce, a session key 
and a blinding factor applied to the nonce, and fur- 
ther comprising the step of storing the initialization 
request message and the initialization response 
message in a recovery database. ss 
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ii. sending the validated blinded certificate 
atorrrically bound to the transaction 
request message to a transaction 
response recipient in a transaction 
response message. s 

The method of claim 5, wherein the transaction 
response further includes making available a prod- 
uct to a party; and/or wherein the transaction 
response further includes obtaining payment for a io 
product. 



The method of claim 5, further comprising the step 
of receiving a transaction acknowledgment mes- 
sage from a registrant acknowledging that the 
transaction response, recipient has received the 
transaction response message. 



8- The method of claim 5, further comprising the step 
of storing the transaction request message and the 
transaction response message in a recovery data- 



A method for recovering from an interruption in an 
electronic transaction, comprising the steps of: 



b. storing the first transaction request message 
in a recovery database; 

c. determining if the unblinded certificate is 
valid; and 

d. if the unblinded certificate is valid, then per- 
forming a transaction response that includes 

i. validating the blinded unvalidated certifi- 
cate to obtain a validated blinded certifi- 
cate, 

ii. sending the validated blinded certificate 
atomically bound to the transaction 
request message to a transaction 
response recipient in a first transaction 
response message, and 

Hi. storing the first transaction response 
message in a recovery database; 

e. receiving a second transaction request mes- 
sage that includes a session key. a nonce and 
a blinding factor applied to the nonce, and that 
atomically binds 
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a. receiving a f irst transaction request message 
that includes a session key, a nonce and a 
blinding factor applied to the nonce, and that 
atomically binds 30 

i. an unblinded certificate, and 

ii. a blinded unvalidated certificate to be 
validated; 
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i. an unblinded certificate, and 

ii. a blinded unvalidated certificate to be 
validated; 

f. determining if the second transaction request 
message has the same nonce, session key, 
and blinding factor applied to the nonce as the 
first transaction request message stored in the 
recovery database; and 

g. if the second transaction request message 
has the same nonce, session key, and blinding 
factor applied to the nonce as the first transac- 
tion request message, then 

i. retrieving the first transaction response 
message from the recovery database, and 

ii. sending the first transaction response 
message to the transaction response 
recipient 

10. A method for auditing an electronic transaction, 
comprising the steps of: 

a. receiving a transaction request message 
that atomically binds 

i. an unblinded certificate. 

ii. a blinded unvalidated certificate to be 
validated, and 

Hi. blinded audit data; 

b. sending an audit request message atomi- 
cally bound to the transaction request message 
to an audit recipient; 

c. receiving an audit response message atomi- 
cally bound to the audit transaction message, 
wherein the audit response message includes 
audit response data; 

d. determining rf the blinded audit data is valid 
using the audit response data. 

11. The method of claim 10, wherein the audit 
response data is determined to be valid if 

i. the audit response data corresponds to the 
blinded audit data received in the transaction 
request message, and 

ii. the audit response data is legitimate. 

12. An apparatus for initializing a series of electronic 
transactions, comprising: 

a. a processor; and 

b. a memory that stores instructions adapted to 
be executed by said processor to. 

i. receive an initialization request message 
that atomically binds authorization data 
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and a Winded unvalidated certificate to be 
validated; 

ii. determine if the authorization data is 
valid; 

iii. if the authorization data is valid, then to s 
validate the blinded unvalidated certificate 

to obtain a blinded validated certificate; 
and 

iv. send an initialization response message 

to a registrant that includes the blinded val- 10 
idated certificate atomically bound to the 
initialization request message. 

said memory coupled to said processor. 

15 

13. An apparatus for performing an electronic transac- 
tion, comprising: 

a. a processor; and 

b. a memory that stores instructions adapted to 20 
be executed by a processor to 

i. receive a transaction request message 
that atomically binds an unblinded certifi- 
cate and a blinded unvalidated certificate 25 
to be validated; 

ii. determine rf the unblinded certificate is 
valid; and 

iii. rf the unblinded certificate is valid, then 

to perform a transaction response that val- 30 
idates the blinded unvalidated certificate to 
obtain a validated blinded certificate, and 
sends the validated blinded certificate 
atomically bound to the transaction 
request message to a transaction 35 
response recipient in a transaction 
response message. 

said memory coupled to said processor. 

40 

14. An apparatus for auditing an electronic transaction, 
comprising; 

a. a processor; and 

b. a memory that stores instructions adapted to 45 
be executed by said processor to 

i. receive a transaction request message 
that atomically binds an unblinded certifi- 
cate and a blinded unvalidated certificate so 
to be validated and blinded audit data; 

ii. send an audit request message atomi- 
cally bound to the transaction request 
message to an audit recipient; 

iii. receive an audit response message 55 
atomically bound to the audit transaction 
message, where the audit response mes- 
sage includes audit response data; and 



iv. determine rf the blinded audit data is 
valid using the audit response data. 

said memory coupled to said processor. 

An apparatus for recovering from an interruption in 
an electronic transaction, comprising: 

a. a processor; and 

b. a memory that stores instructions adapted to 
be executed by said processor to 

i. receive a first transaction request mes- 
sage that includes a session key. a nonce 
and a blinding factor applied to the nonce, 
and that atomically binds an unblinded cer- 
tificate and a blinded unvalidated certifi- 
cate to be validated; 

ii. store the first transaction request mes- 
sage in a recovery database; 

iii. determine if the unblinded certificate is 
valid; 

iv. if the unblinded certificate is valid, then 
performing a transaction response that val- 
idates the blinded unvalidated certificate to 
obtain a validated blinded certificate, 
sends the validated blinded certificate 
atomically bound to the transaction 
request message to a transaction 
response recipient in a first transaction 
response message, and stores the first 
transaction response message in a recov- 
ery database; 

v. receive a second transaction request 
message that includes a session key, a 
nonce and a blinding factor applied to the 
nonce, and that atomically binds an 
unblinded certificate and a blinded unvali- 
dated certificate to be validated; 

vi. determine if the second transaction 
request message has the same nonce, 
session key, and blinding factor applied to 
the nonce as the first transaction request 
message stored in the recovery database; 

vii. if the second transaction request mes- 
sage has the same nonce, session key. 
and blinding factor applied to the nonce as 
the first transaction request message, then 
to retrieve the first transaction response 
message from the recovery database and 
send the first transaction response mes- 
sage to the transaction response recipient. 

said memory coupled to said processor. 

16. The apparatus of claims 12. 13. 14 or 15, further 
comprising a port adapted to be coupled to a net- 
work, said port coupled tosaid processor and said 
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memory. 

17. A medium that stores instructions adapted to be 
executed by a processor to perform the steps of: 

a. receiving an initialization request message 
that atomicalty binds 

i. authorization data, and 

ii. a blinded unvalidated certificate to be 
validated; 

b. determining if the authorization data is valid; 

c. if the authorization data is valid, then validat- 
ing the blinded unvalidated certificate to obtain 
a blinded validated certif icate; and 

d. sending an initialization response message 
to a registrant that includes the blinded vali- 
dated certificate atomically bound to the initial- 
ization request message received in step a. 

18. A medium that stores instructions adapted to be 
executed by a processor to perform the steps of: 

a. receiving a transaction request message 
that atomically binds 

L an unblinded certificate, and 

ii. a blinded unvalidated certificate to be 

validated; 

b. determining if the unblinded certificate is 
valid; and 

c. if the unblinded certificate is valid, then per- 
forming a transaction response that includes 

i. validating the blinded unvalidated certifi- 
cate to obtain a validated blinded certifi- 
cate, and 

ii. sending the validated blinded certificate 
atomically bound to the transaction 
request message to a transaction 
response recipient in a transaction 
response message. 

19. A medium that stores instructions adapted to be 
executed by a processor to perform the steps of: 

a. receiving a transaction request message 
that atomically binds 



to an audit recipient; 

c. receiving an audit response message atomi- 
cally bound to the audio transaction message, 
wherein the audit response message includes 
audit response data; 

d. determining rf the blinded audit data is valid 
using the audit response data. 

20. A system for performing an electronic transaction, 
comprising: 

a. means for receiving a transaction request 
message that atomically binds 

i. an unblinded certificate, and 

ii. a blinded unvalidated certificate to be 
validated; 

b. means for determining rf the unblinded certif- 
icate is valid; and 

c. means for validating the blinded unvalidated 
certificate to obtain a validated blinded certifi- 
cate; and 

d. means for sending the validated blinded cer- 
tificate atomically round to the transaction 
request message to a transaction response 
recipient in a transaction response message. 

21. The system of claim 20, further comprising means 
for auditing an electronic transaction; and/or further 
comprising means for initializing a series of elec- 
tronic transactions; and/or further comprising 
means for recovering from an interruption in an 
electronic transaction. 
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i. an unblinded certificate, 

ii. a blinded unvalidated certificate to be 
validated, and 

iii. blinded audit data; ss 

b. sending an audit request message atomi- 
cally bound to the transaction request message 
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